The present disclosure relates to compressing dependency graphs in online communities. In particular, the present disclosure relates to optimizing software by compressing dependency graphs, including software modules in social networks.
Software may typically be divided into many different modules. These modules are organized into dependency graphs describing the order in which particular modules may be executed (i.e., in the order of module dependency). Depending on a particular application, for example, a social network, extensive code is often necessary to launch and operate the particular application. In the instances where code bases are complex, the dependency graphs may be very large. For example, in some instances of a social network implementation, the dependency graph may be well over 11,000 modules (e.g., javascript). In many cases, especially where the code bases may be large and complex, dependency graphs may include many redundant dependencies. This results in unnecessary requests and operations to load the same modules multiple times.
As one example, a “first” module and a “second” module may be dependent on the same module, for example, a “third” module. To execute, a request to load the “first” module may be received first. Yet, because the “first” module is dependent on the “third” module, before loading the first module, the “third” module loads first, followed by the “first” module. After the “first” module loads, a request to load the “second” module may be received and as the “second” module is also dependent on the “third” module, the “third” module loads yet again. In this particular example, the “third” module is either loaded twice, or the software determines that the “third” module is already loaded. In either implementation, this process of either reloading a module already on the system, or simply determining that it is on the system, is cumbersome and inefficient, especially in cases where a dependency graph is very large and complex.